The growth in demand for telecommunication services is increasing at an ever-quickening pace. The majority of the demand is being driven by the explosion in the use of the Internet and a steady stream of new applications being introduced which further increases the demand for increased bandwidth. Currently, a large portion of the Internet traffic is still carried by circuit switched transport facilities. In the case of Metropolitan Area Networks (MANs), most of the traffic is transported over SONET/SDH based networks most of which were originally resigned for voice traffic. With time, more and more customers are using the networks for transporting data rather than voice.
The requirements for networked communications within the user community have changed dramatically over the past two decades. Several notable trends in the user community include (1) the overwhelming domination of Ethernet as the core networking media around the world; (2) the steady shift towards data-oriented communications and applications; and (3) the rapid growth of mixed-media applications. Such applications include everything from integrated voice/data/video communications to the now commonplace exchanges of MP3 music files and also existing voice communications which have begun to migrate towards IP/packet-oriented transport.
Ethernet has become the de facto standard for data-oriented networking within the user community. This is true not only within the corporate market, but many other market segments as well. In the corporate market, Ethernet has long dominated at all levels, especially with the advent of high-performance Ethernet switching. This includes workgroup, departmental, server and backbone/campus networks. Even though many of the Internet Service Providers (ISPs) in the market today still base their WAN-side communications on legacy circuit oriented connections (i.e. supporting Frame Relay, xDSL, ATM, SONET), their back-office communications are almost exclusively Ethernet. In the residential market, most individual users are deploying 10 or 100 Mbps Ethernet within their homes to connect PCs to printers and to other PCs (in fact, most PCs today ship with internal Ethernet cards) even though the residential community still utilizes a wide range of relatively low-speed, circuit-oriented network access technologies.
The use of Ethernet, both optical and electrical based, is increasing in carrier networks due to the advantages of Ethernet and particularly Optical Ethernet, namely its ability to scale from low speeds to very high rates and its commodity-oriented nature. With the rapid increase in the demand for user bandwidth, and the equally impressive increase in the performance of Ethernet with the LAN environment, the demand for Metropolitan network performance is rapidly increasing. In response, there has been a massive explosion in the amount of fiber being installed into both new and existing facilities. This is true for both the corporate and residential markets.
Transparent LAN Service (TLS), which is also referred to as multipoint-to-multipoint (MP2MP), has been identified as one of the key services to be provided by an Ethernet based metro network. A TLS that provides virtual Ethernet LAN service is called an E-LAN (Ethernet LAN service) in Metro Ethernet Forum (MEF) standard specifications. TLS implementation in MPLS networks is referred to as Virtual Private LAN Service (VPLS) in Internet Engineering Task Force (IETF) drafts.
A TLS creates an emulated LAN segment for a given set of users. It provides a layer 2 broadcast domain that is capable of learning and forwarding using Ethernet MAC addresses for a given set of users.
Today, Ethernet is the predominant technology used for Local Area Network (LAN) connectivity and is gaining acceptance as an access technology as well. This is true especially in Metropolitan Area Networks (MANs) and Wide Area Networks (WANs). In a typical scenario, an Ethernet port connects a customer to the Provider Edge (PE) device. Customer traffic is subsequently mapped to a specific MPLS-based Layer 2 Virtual Private Network (VPN).
Traditional LANs provide unicast, broadcast and multicast services. Locations that belong to the same broadcast domain and that are connected via an MPLS network expect broadcast, multicast and unicast traffic to be forwarded to the proper locations. This requires MAC address learning on a per LSP basis, forwarding unicast destination traffic according to the learned information, packet replication across LSPs for multicast/broadcast traffic and for flooding of unknown unicast destination traffic.
A main goal of Virtual Private LAN Services (VPLS) is to provide connectivity between customer sites situated in the MAN or WAN as if they were connected via a LAN. To accomplish this, a major attribute of Ethernet must be provided, namely the flooding of broadcast traffic and traffic with unknown destination MAC addressed to all ports. To provide flooding within a TLS, all unicast unknown address, broadcast and multicast frames are flooded over the corresponding “pseudowires” to all relevant provider edge nodes that participate in the TLS. Note that multicast packets are a special case and are not necessarily flooded to all VPN members. A pseudowire is a made up of a pair of unidirectional virtual circuit Label Switched Paths (LSPs). Throughout this document, the term pseudowire is used to denote a point-to-point logical link connecting different nodes in the network, regardless of the technology used for its implementation, e.g., MPLS, etc. Depending on the technology, the pseudowire may be an MPLS-VC, a point-to-point VLAN-based trail, an ATM-VC, etc.
A provider edge node uses different techniques to associate packets received from the client with connections. Example techniques include port mapping and VLAN mapping in which the received packet is associated with a connection according to the provider edge device port from which it was received or according to the port from which it was received as well as the VLAN with which it is tagged, respectively. Packets mapped to a TLS connection, are forwarded to one or more of the sites associated with that particular TLS connection. In case of a TLS connection, the forwarding is performed by bridging-capable nodes throughout the network, that bridge between pseudowires dedicated to that TLS. The pseudowires are point-to-point ‘sub-connections’ of that TLS, functioning to connect the bridging-capable nodes. These bridging capable nodes must be able to first associate the received packet with a TLS and then, within the context of the TLS, associate a destination MAC address (or a destination MAC-address and VLAN-tag value) with a pseudowire comprising that TLS in order to forward a packet. It is not practical to require these provider nodes to statically configure an association of every possible destination MAC address with a pseudowire. Thus, a bridging mechanism is required to dynamically learn MAC addresses (or MAC-address and VLAN pairs) on both physical ports and virtual circuits and to forward and replicate packets across both physical ports and pseudowires to which they are associated.
The Ethernet LAN Service (E-LAN Service) is defined by the MEF as a service that provides multipoint connectivity, i.e. it may connect two or more UNIs. Subscriber traffic sent from one UNI can be received at one or more of the other UNIs. In the simplest case, each site (UNI) can be set up to be a member of the same Virtual LAN (VLAN). As new UNIs (i.e. sites) are added, they can be made members of the same VLAN thus simplifying provisioning and service activation.
Bridging functionality operates on the original Layer 2 portion of the packet. The bridge functions to learn new source MAC addresses of ingress packets and to associate them with the outbound pseudowire it is to be sent out on.
Various techniques can be used to provide the forwarding functionality in a TLS. One technique is known as spanning-tree based transparent bridging as described in the IEEE 802.1 standard. In this bridging technique the nodes in the network connect through a tree of point-to-point pseudowires. Standard bridging is performed between them using the pseudowires between them as links over which bridging is performed.
A second bridging technique is a variation of the first one described above and is known as split-horizon bridging in which each endpoint of the TLS is connected through a point-to-point pseudowire to each of the other components. Each endpoint performs a bridging decision as to whether to forward each packet to a specific destination through the point-to-point pseudowire leading to it, or to forward the packet to all or some of the destinations (i.e. through all or some of the point-to-point pseudowires). Thus, all bridges are connected in a full mesh pattern whereby packets pass at most only two bridges. A disadvantage of this technique is that it is not scalable and thus requires a large number of pseudowires as the TLS size increases (in the number of endpoints).
A third technique known as link redundancy uses a single bridging device connected in a dual-homed fashion to a bridging domain using two different pseudowires. The device chooses one of the pseudowires for working at any single point in time.
Note that a single TLS service may be constructed from a number of domains, each implemented using one of the bridging techniques described above.
It is commonly required that provider networks provide packet loss measurements for the transport facilities they provide. Customers typically want information on the number of packets that did not make it to their destination. The end-to-end Service Level Agreement (SLA) measurement protocol described in U.S. Pat. No. 6,643,612 to Lahat et al., entitled “Mechanism And Protocol For Per Connection Based Service Level Agreement Measurement,” incorporated herein by reference in its entirety, provides very accurate calculation of delay, jitter and packet/octet loss for point-to-point connections.
This SLA measurement protocol, however, does not work very well for calculating packet/octet loss for TLS connections. This is because the endpoints of the TLS do not typically maintain per endpoint pair counters. Rather, they only maintain per connection counters of how much traffic was sent and how much traffic was received from the network over a particular connection. The endpoints are not capable of maintaining per endpoint pair counters, i.e. counters at endpoint A indicating how many packets/octets were sent to node B and how many of the received packets were originally sent from node B. The main reason is that node A does not know which is the destination of a packet transmitted over a TLS, since this is decided by the bridging nodes along the way. Further it does not know the origin of the packets it receives. There is an additional problem of scalability to maintain such a large number of counters. Thus, comparing counters at the two ends of a connection (e.g., nodes A and B) such as is done in Lahat et al. cannot be used to measure packet loss for TLS connections.
Thus when a user sends a packet to a provider edge device, they do not know whether the packet will be duplicated in the TLS bridge and forwarded to some or all other end-points of that TLS. Although the packet may have been received once by a single provider edge device, it may be duplicated and forwarded to some or all of the users on the TLS. Packet loss measurements even for unicast are not accurate since it is not known whether each TLS bridge along the way has already learned the forwarding information for the destination MAC-address of each unicast received (and whether it has deleted this information in an aging process). If it has, it will find the MAC address in its tables and will forward it to a single pseudowire. If the bridge does not find the MAC address in its tables, then the packet will be duplicated and flooded to all the other pseudowires connected to it that comprise that TLS. Thus, taking the difference of the sum of all packets going into and out of the TLS will not yield accurate results due to the duplication of packets by the bridges comprising that TLS.
One solution is to use a statistical approach as suggested in a draft paper proposed to the MEF in the course of work on OAM for Ethernet services. In this approach, packet loss is measured in bridging domains (e.g., a TLS) by periodically sending Operation, Administration & Maintenance (OA&M) messages between the bridging domains and counting the messages that arrive successfully. The problem with this approach is that it yields only a rough estimate and not an actual measurement of packet loss. In addition, the estimate is made between two specific endpoints. A scalability problem arises if a global estimation of packet loss for the TLS is desired, as a prohibitively large number of OA&M messages must be periodically sent.